Matching techniques for data transaction requests with private attributes

ABSTRACT

A computer system is provided that includes a paired list of data transaction requests on which a matching process is performed. There are multiple different types of data transaction requests that are stored in the paired list including data transaction requests with midpoint attributes and data transaction requests with discretion attributes. The computer system may determine how the multiple different types of data transaction requests may be match against each other. Two matching processes can be used to determine if a match exists between the first and second sides of the paired list. Matches that are determined at private values are not disseminated to third-parties via public market data feeds.

CROSS REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application No.16/703,372, filed Dec. 4, 2019, now allowed; which is a continuation ofU.S. patent application Ser. No. 16/514,619, filed Jul. 17, 2019, nowU.S. Pat. No. 10,535,092, issued Jan. 14, 2020; which is a continuationof U.S. patent application Ser. No. 15/200,902, filed Jul. 1, 2016, nowU.S. Pat. No. 10,395,302, issued Aug. 27, 2019; which claims the benefitof U.S. patent application Ser. No. 62/188,451, filed Jul. 2, 2015 andU.S. Patent Application No. 62/213,970, filed Sep. 3, 2015, the entirecontents of each being incorporated herein by reference.

TECHNICAL OVERVIEW

The technology herein relates to computing systems that match datatransaction requests. More particularly, the technology herein relatesto matching different types of data transaction requests that includeprivate attributes.

INTRODUCTION

In computing technology, different kinds of data transaction requestsmay be individually handled by different processes (or threads). Eachprocess may be programmed to handle the characteristics or attributesparticular that type of data transaction request. For example, each datatransaction request type may have a corresponding dual-sided sorted listthat is used to match data transaction requests between the two sides. Adata transaction request of type “X” can then be matched against othersimilarly situated type “X” data transaction requests that are presentin the dual-sided sorted list. The segmentation of how each type of datatransaction request is processed may be advantageous because thematching process for each type may only need to account for matching onetype of data transaction request (e.g., A to A and separately B to B).The process segmentation allows for easier expandability of a system asone can add new processes to handle new types of data transactionrequests without affecting how the other processes operate.

However, a potential downside to this type of implementation is thatthere is generally no possibility of matching between the differenttypes of data transaction requests (e.g., A to B). This may beproblematic when there are few data transaction requests of one type andmore of another (or even worse, few of all types).

Accordingly, in these, and other areas of computing technology, newtechniques are continually sought after. In particular, techniques forhow the processes performed by computer systems may be programmed tohandle processing multiple different types of data transaction requestsin a unified manner. Such techniques may be used to organize electronicorder books and perform data transaction request matching for datatransaction requests that have different attributes.

SUMMARY

In certain example embodiments, a computer system creates, updates, andmaintains a single two-sided order list that includes different datatransaction request types. The different types of data transactionrequests include midpoint type data transaction requests and discretiontype data transaction requests. Both of these types have private(hidden) attributes that can affect how the corresponding datatransaction request is sorted into the ordered list and/or how the datatransaction request is matched against other data transaction requests.In certain example embodiments, regular data transaction requests (e.g.,those with no private attributes) are also received and processed.

The features described herein may be combined to form additionalembodiments and sub-elements of certain embodiments may form yet furtherembodiments. This summary is provided to introduce a selection ofconcepts that are further described below in the detailed description.This summary is intended neither to identify key features or essentialfeatures of the claimed subject matter, nor to be used to limit thescope of the claimed subject matter; rather, this summary is intended toprovide an overview of the subject matter described in this document.Accordingly, it will be appreciated that the above-described featuresare merely examples, and that other features, aspects, and advantages ofthe subject matter described herein will become apparent from thefollowing detailed description, figures, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages will be better and morecompletely understood by referring to the following detailed descriptionof example non-limiting illustrative embodiments in conjunction with thedrawings of which:

FIG. 1 illustrates a non-limiting example function block diagram of acomputer-implemented exchange system that implements an example orderbook according to certain example embodiments;

FIG. 2A shows an illustrative non-limiting example of two sides of anexample electronic order book that includes different order types;

FIG. 2B shows multiple different example new incoming orders that may beprocessed against the example order book shown in FIG. 2A;

FIG. 3 is a flow chart of an example matching process implemented forincoming orders according to certain example embodiments;

FIG. 4A is a flow chart showing example post-processing for orders thatare matched and have the mid attribute;

FIG. 4B is a flow chart showing example post-processing for orders thatare matched and have the private discretion attribute;

FIG. 5 is an example computer system according to certain exampleembodiments;

FIG. 6 illustrates a non-limiting example function block diagram of acomputer-implemented exchange system that is configured to receive electorders that have discretion according to certain example embodiments;

FIG. 7 is a flow chart that shares elements with FIG. 3 and showsanother example matching process implemented for orders have electpreferences according to certain example embodiments;

FIG. 8A shows an illustrative non-limiting example of two sides of anexample electronic order book that includes different order types; and

FIG. 8B shows multiple different example new incoming that may beprocessed against the example order book shown in FIG. 8A.

DETAILED DESCRIPTION

In the following description, for purposes of explanation andnon-limitation, specific details are set forth, such as particularnodes, functional entities, techniques, protocols, etc. in order toprovide an understanding of the described technology. It will beapparent to one skilled in the art that other embodiments may bepracticed apart from the specific details described below. In otherinstances, detailed descriptions of well-known methods, devices,techniques, etc. are omitted so as not to obscure the description withunnecessary detail.

Sections are used in this Detailed Description solely in order to orientthe reader as to the general subject matter of each section; as will beseen below, the description of many features spans multiple sections,and headings should not be read as affecting the meaning of thedescription included in any section.

Overview

In certain example embodiments, a computer system is acomputer-implemented trading exchange system (exchange) that stores twosorted lists (also referred to as an “order book”) of received datatransaction requests (also referred to as “orders” herein). Certainexample embodiments relate to incorporating one or more (e.g., two ormore) different data transaction request types into a single electronicorder book (e.g., per instrument). In certain examples, this may includecombining wholesale order types with regular “retail” order types. Thesedifferent order types may be matched against one another. The differenttypes of data transaction requests include discretion orders(“discretion”) and midmarket block orders (“mid” or “midpoint”) that maybe added to a single electronic order book that also includes retailorders (e.g., those orders with information published to third partiesand generally available to any counter party customer).

FIG. 1 illustrates a non-limiting example function block diagram of acomputer-implemented exchange system that implements an example orderbook according to certain example embodiments. FIG. 2A shows an exampleof an order book that may be stored in the system of FIG. 1. FIG. 2Bshows multiple different example new incoming orders that may beprocessed against the example order book shown in FIG. 2A. The matchingof orders shown in FIGS. 2A and 2B may be implemented according to theprocess shown in FIG. 3, which may be implemented on the exampleexchange system of FIG. 1. FIGS. 4A and 4B shows how mid and discretionorders are handled after being matched. FIG. 5 is an example computersystem that may be used to implement the features in FIGS. 1-4B and6-8B. FIG. 6 illustrates a non-limiting example function block diagramof a computer-implemented exchange system that is configured to receiveelect orders that have discretion according to certain exampleembodiments. The example process shown in FIG. 7 may be implemented onthe system shown in FIG. 6 (or FIG. 1). FIG. 8A shows an example orderbook that may be stored in the system of FIG. 7 (or FIG. 1) and FIG. 8Bshows multiple different example new incoming orders that may beprocessed against the example order book shown in FIG. 8A.

FIG. 1

By way of introduction, FIG. 1 shows a non-limiting example functionblock diagram of an automated exchange computer system 100 (“exchange”100 hereafter) that implements an example electronic order book 110 andmatching engine processor 108 according to certain example embodiments.Automated exchange computer system 100 may be implemented on one orcomputer computing servers or systems; such as the system shown in FIG.5.

Matching engine processor 108 can be a combination of hardware (e.g., ahardware processor, such as a central processing unit) and software orjust hardware (e.g., a suitably designed application-specific integratedcircuit or field programmable gate array). The matching engine processor108 generally handles incoming orders and attempts to match incomingorders against those orders stored in the electronic order book 110. Incertain example embodiments, in addition or alternatively to matchingincoming orders, the matching engine processor 108 attempts to matchorders that are already stored in the electronic order book 110 (e.g.,attempts to match two “resting” or “passive” orders). As explained ingreater detail below, market conditions (e.g., the state of the orderbook for a particular instrument) may change and cause two orders thatwere previously stored in the order book to match (or cross). Inresponse to such a change, the matching engine processor 108 mayidentify two orders that can match and trigger the execution of a tradebetween those two orders.

Electronic order book 110 can be a data structure (e.g., a database,flat file, list, etc. . . . ) that holds multiple entries inelectronically accessible memory (e.g., RAM, cache, registers, hard diskdrives, etc. . . . ). Typically, an electronic order book has two sides,side X and side Y, which can be bid and offer/ask or buy and sell sidesfor the same instrument in the same electronic order book. An example ofsuch an order book is shown in FIG. 2A where sides 200 and 210 of anorder book for a single instrument are shown.

In certain example embodiments, the instrument identifiers used in theorder book can be associated with, for example, bonds (e.g., U.S.treasury notes of various denominations), stocks, or the like. While anytype of instrument may be used, the techniques herein may be moregenerally useful for those instruments that have typically lowvolatility. In certain examples, a midpoint order may be preferred forbenchmark treasuries, where large size is often desired. Benchmarkinstruments can trade at the same minimum screen tick bid/ask spread formost of the trading day and thus orders that operate between the spreadcan be useful for providing liquidity. Midpoint orders could be used formany other products, including treasury bills, short shorts, coupon androlls, and other instruments. Discretion orders may be preferred forcoupon rolls and other instruments that typically operate with slightlywider bid/offers spreads than, for example, benchmark treasuries.

In any event, each newly received order for a given instrumentidentifier that is not matched (or has a leftover quantity after asuccessful match) is added to one of the two sides depending on the typefor that order (e.g., whether it is a buy or a sell). Orders added toelectronic order book 110 are stored until they are canceled (e.g., viaa client or system command) or matched against other electronic orders.

In certain example embodiments, orders placed into the electronic orderbook 110 may be marked as inactive and thus skipped during a matchingprocess performed by the matching engine processor 108. An inactivecondition for an order may be triggered by the order not meeting certainmarket conditions. For example, a midpoint order may be marked inactiveif the bid/offer spread is greater than a threshold spread (or if theorder book is one-sided such that there are only bids or offers in theorder book, but not both). For example, referring to FIG. 2A, if theorder book for an instrument only contained bids 200, then midpointorder 203 may be marked as inactive (but still valid) or invalid.Alternatively, midpoint order 203 may be marked as inactive (but stillvalid) or invalid if the displayed ask side for the order book is toofar from the displayed bid side (e.g., the spread is too large). Thus,the order book for an instrument shown in FIG. 2A may have a rule thatrequires the displayed spread to be 2 screen ticks or less (e.g., a bidof 100 and an offer of 102). Any spread that is outside of that range(e.g., the highest bid of 100 and the lowest offer of 103) willautomatically invalidate orders that require the threshold spread to bewithin the defined range.

Returning to FIG. 1, electronic orders 104 can be submitted by clientcomputer systems 102 to exchange 100 for matching and/or entry intoelectronic order book 110. Client systems can include personalcomputers, mobile devices, automated computer systems, and the like.Generally, client systems 102 are any computer system programmed tointerface with exchange 100 for the purpose of submitting electronicorders 104.

Electronic orders 104 are submitted in the form of electronic datamessages that include a data transaction request for a correspondingorder (e.g., a data transaction request to match the order to a pending,or future, order). The electronic order may specify a client ID thatidentifies the client sending the request (e.g., a company, person, etc.. . . ), an instrument ID that identifies a particular instrument (e.g.,a ticker symbol or the like), transaction type ID that may identify, forexample, whether the request is associated with a sell or buyinstruction, an order attribute that specifies whether this a regularorder, a discretion order, a midpoint order, or the like, a quantityvalue that indicates the quantity of the order, a MinOrder value thatindicates a minimum order amount that this order can be matched against,and a price value that indicates a particular price for the ordersubject to the data transaction request. In certain examples, otherfields may be defined in the electronic order and/or some may beoptional.

For example, a midpoint order may not require a price value as the priceis automatically determined as the midpoint price between the listedbid/offer. Instead, a midpoint order may require a minimum and/ormaximum price at which the midpoint order may execute (this “limit”parameter may effectively set a range in which the mid order may bematched with other orders). It will be appreciated that a midpoint pointmay be entirely hidden (private) such that no aspect of the order isresponsively broadcast to general third parties when the midpoint orderis entered, matched against, or otherwise interacts with an order book.

In other examples (e.g., in the case of a discretion order), theelectronic order may also specify the price for the displayed quantityof the order, the quantity to be publically shown, a number ofdiscretion ticks for the hidden portion (a private attribute of theorder) of the order (e.g., tick amount that is less than, such as afraction of, a standard screen tick quantity), the total size of theorder (a private attribute of the order), and the amount of the orderthat is eligible to be matched with discretion (a private attribute ofthe order). In certain examples, the electronic order may specify atotal size value and a publically visible value (e.g., such that thesize of the private part of the order is the difference between thetotal size and the visible value). In certain examples, the electronicorder may specify a hidden size value (a private attribute of the order)and a publically visible value (e.g., such that the total size of theorder is the sum of the hidden and visible values). In certain examples,an order may specify the amount of the order that may be matched at theprice allowed by the discretion. This amount may be less than the totalamount of the order. Thus, for example, a discretion order may display25, have a total quantity of 1000 (e.g., 975 of the 1000 is a privateattribute), and have 500 of that 1000 eligible to be traded at 1discretion tick from the displayed or publically broadcast price. Incertain examples, a private attribute includes a number of discretionticks. Based on this value and the public price of the order, adiscretion price can be calculated. For example, order 201 has a publicprice (value) of 100, with a private attribute of 2 discretion ticks.Accordingly, the maximum private value at which order 201 can trade is101 (assuming the 0.5 discretion tick increment used in FIG. 2A).

As discussed herein, public refers to information (e.g., priceinformation, size information, trade information, etc. . . . ) that isgenerally made available to third parties via an electronic data feed.The parties that receive this information are generally not associatedwith the order and/or trade. This aspect may also be referred to as“displaying” information to such third parties.

Conversely, private (sometimes also referred to as hidden or darkherein) information generally refers to information for which thedetails are not provided to such third-parties. Instead the informationis made available to the parties associated with the trade, order,match, etc. . . . This also includes the exchange itself, third partyregulatory systems, and the like. Thus, for example, an order may have apublic price (e.g. that is “displayed” or provided to third parties), aprivate price (e.g. that is not expressly displayed or provided to thirdparties), or a combination thereof (e.g., a public price value and aprivate price value). In certain examples, when a match is determinedbetween a “public” price and a “private” price, such match informationis not made public. The “public” information in such a case istransformed into private information. This is discussed in greaterdetail below in connection with FIG. 3 and the examples of FIGS. 2A and2B. It will be appreciated that discretion type orders may have privateattributes (e.g., private discretion attributes) and midpoint typeorders may also have private attributes (e.g., private midpointattributes). Other order types with private attributes may be similarlyused.

Returning to FIG. 1, electronic data messages that include electronicorders are received by network interface device 106 (e.g., a networkcard). The received messages are parsed and their contents (e.g., theelectronic order included therein) passed onto matching engine processor108. As discussed above, the matching engine processor 108 attempts tomatch the incoming order against other passive or resting orders alreadypresent in electronic order book 110. The matching engine processor 108(and/or another processor) may employ the technical algorithm shown inFIGS. 3, 4A, 4B, or 7.

In certain example embodiments, if no match is found, then the order isadded to electronic order book 110 on the side indicated by thetransaction type ID (e.g., whether a bid or offer) and the attributes ofthe electronic order are similarly populated with the parameters fromthe electronically submitted order. In certain example embodiments, theorder is placed into the order book directly and the matching process isthen run for the newly updated order book. In certain exampleembodiments, the matching engine processor 108 runs by attempting tomatch the incoming order at the displayed price and then runs a furtherprocess to determine if any passive orders in the order book crossand/or match.

In any event, if the newly submitted order is added to the order book,an acknowledgement is sent to the order submitting client system 102. Ifthe order is a publically lit order (e.g., a retail order with noprivate attributes), then the details of that order may be transmittedto third party external computer systems via network interface. Thedetails of the order may be included in a data stream (e.g., a real-timemarket data feeds) to which customers subscribe (e.g., such as NASDAQTotalView-ITCH℠). Notably, orders that are not public (e.g., “dark”orders or private order details, etc.), are not included as part of suchcustomer data streams. In certain examples, public portions of an order(e.g., a display price and/or display size) are publically madeavailable, while the private attributes are not. In certain examples,notification of a hidden order may only be sent back to the ordersubmitting client.

If a match is found, then a record of that match may be generated anddistributed through network interface 106 or network interface 112. Ingeneral, if the match is at a price that is nota displayed price, thenthe trade details are not included as part of real-time public datafeeds. Instead, confirmation of such orders are only provided to thecounter-parties for the trade. Thus, for example, if the match isbetween two orders that are not public (e.g., two mid orders), then arecord or acknowledgement is only sent to the two customers involved inthe order and is not included in a public data stream. Alternatively, ifa match is performed at a publically listed price (e.g., the listedbid/offer price) then a record of the trade may be included in thepublic data stream. In certain examples, upon identification of a match,the trade between the contra orders is executed and post-processing forthe trade may be carried out by external computer exchange systems 114(e.g., settlement, etc. . . . ).

In general, trade information updates may work as follows: trades thatinvolve orders with the mid attribute will trade in the dark (e.g.,customers associated with the trades are the only parties that areimmediately notified when the trade occurs). Thus, even if a “regular”order (e.g., not a discretion order or a midpoint order) is matched witha midpoint order, the details of that trade will not be made publicallyavailable via real-time data feeds. Similarly, if a discretion orderrelies upon a private discretion attribute to find a match, then thedetails of that trade will not be publically available. If, however, adiscretion order is matched at its displayed price, then trade detailswill be made public via example real-time market data feeds. In certainexample embodiments, all trades (including those matched using privateattributes) may be summarized at the end of a trading day and presentedin aggregate or detailed form.

FIGS. 2A-2B

Turning to FIG. 2A, an example order book is shown with bid side 200 andask side 210. This example order book may be included in electronicorder book 110.

Different instruments may have different attributes for how differentorder types may be handled by the order book. In the example shown inFIG. 2A, the instrument has a screen tick of 1 (e.g., 100, 101, 102,etc. . . . ). These screen ticks represent valid displayed bids oroffers that may be entered for any given order. For example, order 201was entered with a displayed price of 100 (e.g., a public value or apublically visible value). In addition to having a screen tick of 1, thevalid discretion tick amount for this instrument is 0.5. Generally, thediscretion tick amount will be a fractional amount of the screen tickamount, such as, for example ½, ¼, ⅛, etc. . . . of a screen tick.However other values are also possible.

In certain examples, orders with private attributes (e.g., midpointorders and/or order that can be executed with discretion) may requirethe order size of counter-party parties to be greater than or equal toan execution size requirement in order to be eligible to match againstthe private attributes (e.g., prices or volumes) of the order. Forexample, orders that are eligible to match against either mid or ordersexecuted with discretion, must have a quantity that is equal to orgreater than 100. In certain example embodiments, this minimum blockexecution size may differ for mid orders and orders executed withdiscretion (e.g., one may 100 and the other 200). Examples of privateattributes include the discretion order quantity, a discretion tickamount, a total order size (e.g., other than the displayed order size),a discretion price, an order size of a midpoint point order, and thelike.

Another property for an instrument may be a size requirement that anorder must meet to be eligible to make use it's private mid and/ordiscretion attribute. In the example in FIG. 2A, this size require is100 and thus only orders that meet or exceed this size threshold can belabeled with the discretion or mid attribute. In certain exampleembodiments, if an order initially has sufficient size to meet thisrequirement, but the size of the order is decreased because, forexample, a portion has been matched, it may lose the mid and/ordiscretion attribute. Order 204 is an example order that previously hadthe discretion attribute. But the attribute was removed because aportion of the total quantity was matched against a contra-side order(which reduced the size to below 100). In certain example embodiments,customers may be notified upon such a change in status and given theopportunity to increase the size of their order to meet the minimum sizerequirement. In certain examples, orders that are lower than the minimumsize requirement are canceled and a notification of such cancelation issent to the customer.

In certain example embodiments, instruments may also define a maximumbid/offer spread in which discretion and/or midpoint orders are valid.If the spread exceeds this value, then midpoint orders and/or discretionorders will be marked as inactive or canceled. The example shown in FIG.2A is using a max bid/offer spread of 2 so that if the bid/offer spreadexceeds 2 the midpoint orders in the order book will be marked inactive.

Each order in the order book may have one or more parameters. An ordercan specify a displayed price for that order. Certain orders, such asmidpoint point order 203, may not include a price because the price forthe midpoint order is dynamically calculated based on current marketconditions. In the example shown in FIG. 2A, and assuming the totalorder book is represented via sides 200 and 210, the dynamicallycalculated price for order 203 will be 101—the midpoint between thecurrent bid/offer spread of 100/102.

Another parameter is the displayed size. This size value is the sizeshown (e.g., is public) to other customers (e.g., via a market datafeed). Thus, order 201 is displaying a bid of 25 at 100. The displayedsize may be different from the “total” size of the order as order 201has a total size of 500. In such a situation, the displayed size may notchange even if an order for 25 at 100 is executed for order 201. Rather,the total size of order 201 may decrease by 25 (e.g., from 500 to 25).

Other parameters relate to orders executed with discretion. Discretionticks indicates the amount of discretion ticks (in this case 0.5) fromthe displayed price of the order that a match is allowed to be made.Accordingly, order 201 can execute against contra-side orders for 100.5and/or 101. As noted above, for a contra order to be eligible to matchagainst an order using discretion (such as order 201), it must meet theminimum block size requirement.

The attribute parameter indicates the type of order that is beingexecuted (e.g., regular if blank, midpoint, discretion, etc. . . . ).Other types of orders may also be included. For example, instead ofspecifying discretion ticks, an order by indicate a specific price atwhich it may discretely execute. The order may only execute at thatprice or may execute at any valid price between the current displayedprice and the discrete price.

The timestamp parameter is included to indicate when an order wasreceived and/or otherwise last modified. The timestamp parameter is usedwhen arranging the order book in a price/time manner.

The limit parameter is used to place a floor and/or ceiling for amidpoint order. Thus, for example, order 203 will not exceed a price of102—even if the actual midpoint of instrument represented by the orderbook in FIG. 2A moves beyond 102.

Accordingly, for the order book represented in FIG. 2A, the currentbid/offer spread is 100/102 or 2 screen ticks and there are 5 orders inthe bid side 200 of the order book and 2 orders in the offer side 210 ofthe order book

FIG. 2B shows multiple different example new incoming orders that may beexecuted against the example order book shown in FIG. 2A. Orders 220,240, and 250 are new offer orders and order 240 is a new bid offer.These are example orders that could be executed according to theprocesses shown in FIGS. 3, 4A, 4B, and/or 7. FIG. 3

FIG. 3 is a flow chart of an example matching process implemented forincoming orders according to certain example embodiments. The matchingprocess described herein may be implemented as part of matching engineprocessor 108 and/or the processing system 502 from FIG. 5.

At step 300, the process is waiting for a new incoming order and at step302 a new order is received (e.g., contained in an electronic datamessage submitted from a client system to an exchange computer systemand via network interface). In response to reception of the new order,the order is parsed to determine its parameters in step 304.

As part of the parsing and determination step, a check is run todetermine if the submitted parameters for the new order are valid. Forexample, if the new order is a midpoint order, but the size of the orderis not equal to or greater than the required block size for a midpointorder, then the new order may be invalid and a responsive electronicdata message indicating as such may be sent in response to the ordersubmitting client computer system. As another example, if the new orderis a midpoint order and the market is not a valid two-sided market (orthe bid/offer spread is greater than the midpoint allowable spread),then the order may be valid, but marked as inactive (or another similarproperty). In certain examples, a valid order may be placed into theorder book as an inactive order and may be activated upon adjustedmarket conditions (e.g., when there is a valid bid/offer spread withinthe maximum midpoint spread threshold). In this type of exampleimplementation, an electronic data message may be sent to the ordersubmitting client that the market (e.g., the bid/offer spread is toogreat) for the give instrument was not valid for the order theysubmitted, but the order was placed into the order book as an inactiveorder and will be activated when market conditions meet the requiredconditions.

After verifying the parameters of the incoming order, then the computersystem determines if the new order is a midpoint order at step 306. Ifthe new order is a midpoint order, then the process skips to step 322.If the new order is not a midpoint order, then the process proceeds tostep 308. The reason why midpoint orders skip steps 308, 310, etc. . . .is that midpoint orders may not be processed as an aggressing orderbecause they are placed at the dynamically determined midpoint price ofthe market. Instead, they are added to the order book at step 322 andthen all of the resting orders in the order book are processed todetermine if there are any matches or crosses.

Assuming the new order being processed is order 220 from FIG. 2B, withthe current state of the electronic order book represented by 200 and210 in FIG. 2A, the process determines that order 220 is not a midpointorder and proceeds to step 308 where the current order book is sorted ona price/time basis.

While the preferred embodiment sorts the other book on a price/timebasis, other types of sorting may be implemented according to certainexample embodiments. For example, the order book may be sorted based on,or take into account, the size of the order. It will be appreciated thatsorting of the order book may occur at different points in the processand/or the order book may be maintained in a price/time order (e.g.,such that new orders are properly inserted into the order book on aprice/time basis).

In certain example embodiments (e.g., referring to the sorted order bookshown in FIG. 2A), sorting on a price/time basis includes sorting basedon the private or “hidden” price associated with the orders. In thiscase, midpoint order 203 is not visible (public) but is sorted (e.g.,logically) to the “top” of the order book because the dynamic price oforder 203 (i.e., 101) is the highest price bid price for the instrumentand its timestamp is older than order 201.

Order 201 has a displayed price of 100 and a timestamp of 8, but issorted just after order 203 on a price/time basis within the order bookbecause order 201 has 2 possible discretion ticks and accordingly canmatch offers of 101. In other words, the orders in the order book aresorted on a price/time basis by taking into account the discretion price(e.g., the private attribute) that discretion orders may (but are notrequired) to trade at.

In certain example embodiments, when an order has its private attributeremoved, it may be resorted or placed at a different priority within theorder book. For example, consider that order 204 previously had a totalsize of 300 and 2 discretion ticks and a new offer came in at 101.Because order 204 has a timestamp of 3 it would have has priority overorders 203 and 201 at the 101 price and it would have matched againstthe incoming 250 offer order. However, after matching with the 250 offerorder the total size of order 204 would be less than the 100 order sizethreshold that is allowed for discretion orders. Thus, the privateattribute would be removed and the resulting order would be sortedbehind the other orders that are operating at a hidden price.

In certain example embodiments, the order book is sorted based on thetotal (or the displayed) size of the incoming order. For example, if theincoming order is 230 shown in FIG. 2B, the order book may be sortedwithout taking into account the hidden price (e.g., the private value)of the midpoint and/or discretion orders. This is because order 230 doesnot meet the block size requirement to be eligible for matching againstcontra-side hidden orders. Instead, order 230 only matches at thedisplayed price and accordingly the order book may be sorted usingprice/time basis that only uses the displayed price of the restingorders. Thus, in this example, order 202 will be the first or top orderin the order book followed by order 204. Conversely, if order 220 is theincoming order, then the order book may be sorted taking into accountthe hidden price of the orders.

In any event, at step 308 the order book is sorted and at step 310 amatching process is performed using the price/time sorted order book.During this matching process all new orders are treated as regularorders at which a match is attempted using the displayed price of thenew order. Alternatively, if the new order is an order that can executewith discretion, the new order can attempt a match at its discretionprice(s).

At step 312 if a match is found, then the process determines if thematch is at a private price (also referred to as a price that is hiddenor dark) at step 314, if the match is at such a price then the processonly transmits the details of the resulting trade at step 318. If thematch was not at a private price (e.g., private for either order), thenthe details of the trade are published to market-data feeds that can besubscribed to or otherwise viewed by third parties.

After transmitting the details of the matched trade, then at step 320the process determines if there is any remaining quantity for thematched orders. In certain example embodiments, even if there isremaining quantity the remainder may be canceled (e.g., if the remainingquantity is below the block size threshold) and the process returns towaiting for additional orders are step 300. In certain exampleembodiments, as described below, the process may still execute restingorder processing as set forth in steps 326, 328, and 330 by takingbranch 332. In certain examples, after finding a first match, theremaining size of the new order may be used by the matching engineprocessor to determine if another match at step 312 can be identified.

Alternatively in step 320, if there is a remainder quantity to the neworder (e.g., that has not been matched) or if there was no match for thenew order in step 312, then that order and its remaining quantity areadded to the order book at step 322. As noted above, if the processdetermined the new order was a midpoint order, then it is added to theorder book at step 322 at the dynamically determined midpoint price forthe instrument.

As discussed above, the new order may be added to the order book on aprice/time basis. Thus, for example, order 220 may be added at the topof the order book because its possible discretion price is lower thanorder 212. Alternatively, it may be added as the last order in the orderbook because its displayed price is equal to the displayed prices of theexisting orders and its timestamp (9) is newer than the existing orders.

After adding the new order to the order book at step 322, the processthen performs a matching process across the order book to determine ifany matches can be formed. This process uses the private discretionattributes of all of the orders when attempting to form a match. Thus,for example, a new order would not be executed with its discretion ticksin step 310 (although, as discussed below, resting orders may be matchedbased on their discretion attribute in step 310), but rather thediscretion ticks for the new order would be used when performing thematching process in step 326.

After performing the matching process in step 326, then if there is amatch in step 328, then the process handles post match processing basedon the order types involved in the match. Specifically, midpoint ordersmay have post match processing as described in FIG. 4A and discretionorders may have post match processing described in connection with FIG.4B.

If no match is found in step 328, then the process returns to step 300to wait for newly submitted orders.

The following discussion illustrates how the example incoming orders inFIG. 2B may be executed according to the process shown in FIG. 3. Orders220, 230, 240, and 250 are all assumed to be new orders with a restingorder book as shown in FIG. 2A.

If the new order is order 220 (a discretion order), then step 310 willdetermine if a match can be accomplished using the displayed price oforder 220 against the displayed or hidden (e.g., discretion or midpoint)price of resting orders 200 in FIG. 2A. Thus, with a displayed offer of102, there is no bid that can match with order 220 and accordingly theresult of step 312 is that no match is found (either using discretion ofthe resting orders or not) and order 220 is added to the order book(side 210) in step 322.

After adding order 220 to the order book in step 322, the processattempts to find matches from the resting orders in the newly updatedorder book. This process will use the hidden prices of both sides of theorder for determining if a match is possible.

Accordingly, order 220, using 2 of its 3 permitted discretion ticks,will match against midpoint order 203 at a price of 101 for a size of400. This will decrease the size of order 220 and fulfill order 203.

Step 326 continues performing the matching process and identifiesanother match between order 220, with 3 permitted discretion ticks, andorder 201, with 2 permitted discretion ticks. Here, there are twopossible prices at which order 201 and order 220 may match, 100.5 (using3 ticks from order 220 and 1 tick from order 201) and 101 (using 2 ticksfrom each order). In certain example embodiments, the price is set atthe full discretion price of the aggressing (or newer order) and maythus be set at 100.5. In other examples, a price for a trade of crossingdiscretion orders may be determined such that each order gives up adiscretion tick if the aggressing order has crossed the resting order by2 ticks. If there is a three tick (or one tick) difference between thediscretion prices of the crossing orders then the aggressing order wouldgive up the extra tick and the resting order give up 1 tick (or none inthe case of a 1 discretion tick difference). In other exampleembodiments, the price may be set at 101.

In certain example embodiments, the price of the match is determined tofavor the older of the two orders being matched, such that when there isa choice between which order will use a discretion tick to achieve amatch, the newer order will use its tick. Thus, in this example, order201 is the older of the two orders and accordingly order 220 will betreated as the aggressive order and “use” its discretion tick to achievea match at 100.5. In other words, when the discretion prices of twoorders cross, the resulting trade price will be the discretion price ofthe incoming order (in the above example the incoming order is the newerof the two orders and is the crossing order), not the discretion priceof the resting order (order 201). Other techniques for determining theprice at which the match is accomplished may be used.

Accordingly, two matches have been found between order 220 and 203 andorder 220 and 201. After finding these two matches, step 326 continuesdetermining if further matches can be found and identifies a matchbetween order 202 and order 220 at a price of 100.5. Accordingly, order220 will match first against order 203, then against order 201, andfinally against order 202.

For each of the three matches, step 328 is executed and step 330,post-match processing is similarly executed for each of the matches. Thepost-match processing for midpoint orders is described in connectionwith FIG. 4A and the post-match processing for discretion orders isdescribed in connection with FIG. 4B. For example, order 220 has beenmatched for 1400 quantity and thus has a remainder of 100. This sizesatisfies the minimum discretion requirement and thus order 220 is keptin the order book on side 210 with a displayed price of 102, a displaysize of 75, and a total size of 100, with 3 discretion ticks. Orders201, 201, and 202 are handled according to the respective processesshown in FIGS. 4A and 4B (depending on the order type).

As all of these matches were at hidden or dark prices and accordinglythe details of the trades are not pushed to market-data feeds. Instead,only the counter-parties to the respective trades will be notified.Thus, the customer that submitted order 220 will know details of each ofthe three trades and the customers associated with orders 203, 201, and202 will only know the details of their specific trades, but not theother trades (e.g., the customer for order 201 will know be notified ofthe trade concerning order 203).

Turning to another example where order 230 is a new order for theinstrument with the order book shown in FIG. 2A (note that this exampleis independent of the results of the above discussed example of order220). As noted above, in step 308, the order book may be sorted based onthe order type of the incoming order. In this case, the order is aregular order and does not satisfy the minimum block size requirement inorder to be eligible to match at a discretion or midpoint price. In sucha case, the order book may be matched only using the public price andthe timestamp (e.g., in FIG. 2A order 202 would be at the top of theorder book).

Here, order 230 is an offer of 75 at 100 and is a regular order withouta midpoint or discretion attribute. In step 310, the executing processdetermines if there is a match to be made at the price (100) of order230. The order(s) that order 230 matches against may depend on how theorder book is sorted in step 308. If the order book is sorted based onthe displayed price, order 230 will match first against order 202 (witha timestamp of 1). Alternatively, if the order book is sorted to factorin the hidden discretion price of the orders, then order 230 may matchagainst order 201.

The matching process may also depend on whether the new order is matchedagainst the displayed size of the resting orders or is matched againstthe total (or reserve) size of the resting orders. For example, order202 displays a size of 50, but has 500 total size. Thus, order 230 maybe matched against order 203 for the full 75. This may result indecreasing the total size of order 202 by 75, but keeping the displayedsize at 50. Alternatively, order 230 may match using only the displayedsize of the resting orders. In such an example (assuming the order bookis sorted based on the displayed price), order 230 will match for 50against order 202, then 10 against order 204, and 15 against order 205.In certain instances, orders that match with their displayed size may bere-clipped with some of their reserve. In certain example embodiments,an order that fulfills its displayed size will be automaticallycanceled—even if there is size remaining in reserve for that order.

In any event, as can be seen, offer order 230 will be fulfilled at aprice of 100. As the prices for each of these orders is at a publicprice, the details of the one or more trades will be made availablethrough a market data feed. As there is no remainder, then the processproceeds back to step 300. The process may also take optional branch 332and perform a matching process for the resting orders (discussed in moredetail below).

In certain examples, the matching process for discretion orders mayoperate according to an example modification to order 230 with adisplayed/total size of 500. In this example, the matching process willfind matches with order 203 and 201 at a price of 101 because the neworder meets the minimum discretion and midpoint size requirements. Thus,if a new order crosses the discretion price of a resting order (assumingan existing valid two-sided market), the resting order may give up itsfull discretion amount. Alternatively, in other example matching engineprocesses, the order may execute at the displayed price of the incomingorder. In certain example embodiments, the matched price may beone-discretion tick off the full discretion price of the passive order.

In the next example, bid order 240 of 101 for 1000 is received as a neworder. This is a regular order without discretion and proceeds to step310 where the process attempts to match order 240 against the restingorders in the order book. However, there are no possible matches to befound with a bid of 101. Accordingly, order 240 is added to the orderbook at step 322.

As a result of adding order 240 to the order book, the displayed spreadof the instrument is adjusted. Previously the bid/offer spread was100/102. With the addition of order 240 to the order book, the bid/offerspread is now 101/102. As the spread has changed, the midpoint of themarket has also changed. In response to detecting a change in thecalculated spread of the instrument, the midpoint price of any midpointorders will be adjusted. In this example, the midpoint price of order203 will be dynamically adjusted from 101 to 101.5—the new midpoint ofthe market. Thus, when new orders are added to the order book in step322, the order book is re-sorted, which may involve recalculating themidpoint price of any midpoint orders.

The process proceeds to step 326 to determine if there are any matchesto be made from the newly updated order book. In this example with order240, the addition of this order has caused the midpoint price of order203 to be 101.5, which is within the discretion range of order 212.Thus, the addition of order 240 ends up causing a match between order203 and order 212 at 101.5 for 400. This resulting trade is a hidden ordark trade and is therefore not made available to third partymarket-data feeds.

As a modification to the above example, consider if order 203 has alimit price of 101. This parameter would mean that order 203 would notbe dynamically re-priced to 101.5 as it exceeds the stated limit price.Instead, order 203 may be marked as inactive, canceled, and/or anotification may be sent to the customer regarding the new midpointprice of the market and the invalid nature of midpoint order 203(assuming a limit price of 101).

In certain example embodiments, if a customer updates the limit price ofa midpoint order (or other type of order), then the timestamp of theorder is also updated to be the timestamp of when the limit was updatedas opposed to when the order was initially submitted. This feature mayprevent customers from always being “first” for midpoint orders while atthe same time shielding themselves from changes in the market.Similarly, an adjustment in the discretion tick or price amount maycause the system to update the timestamp associated with thecorresponding order. For example, a customer may want to update thediscretion tick amount of order 201 as a result of the market movingbecause of new order 240. If the discretion tick amount is updated to 3for order 201 (which would result in a match with order 212), then thetimestamp for order 201 will also be updated to be the current timestamp of the system. Other types of interactions with order parameters(e.g., price) that are currently resting in the order book may cause thetimestamp for the order to be updated.

In certain example embodiments, if a customer updates the displayed sizeand/or total size of a resting discretion or midpoint order, then thetimestamp will not be updated for that order. In other exampleembodiments, the time stamp for the order may be updated.

The decision of whether timestamps are updated for modifying certainparameters of an order may be based on the type of instruments orsecurity being updated.

Returning to the examples in FIG. 2B, order 250 is a midpoint order andaccordingly the branch at step 306 will cause the processing to skipsteps 308, 310, etc. . . . and proceed directly to step 322 where order250 is added to the order book as resting order. The current midpoint ofthe instrument is 101 and the process proceeds to step 326 where thematching engine determines if there are any matches to be made from theresting orders. In this case, order 250 will match against order 203 at101 for 400 and match against order 201 at 101 for 500 (using the twodiscretion ticks of order 201). Order 250 will be left with a size of100 (which satisfies the minimum midpoint block requirement) and left inthe order book as a midpoint order on the offer side. As there are twomatches, post processing will be performed for both trades at step 330for the orders involved in the trade.

Order 260 is another example that is like order 220, but with a price of101 and a discretion tick of 1. In this example, order 260 is matchedusing the displayed price of 101, in step 312, with order 203 at 101 andorder 201 are 101. These trades are processed in the dark at step 314.The remaining quantity, 600, is added to the order book, and thematching process in step 326 is performed. In this matching process, theremaining quantity of the order 260 is matched with order 202 for 500 at100.5. This is also a trade that occurs in the dark.

In certain example embodiments, an alternative matching process may beused. Specifically, rather than using the displayed price of an orderwhen matching in 310, the aggressing order is processed based on itsfull discretion price. With such a process, order 260 would be matchedat 101 for 400 and then also matched at 100.5 for 500 twice, once fororder 201 and once for order 202. The remaining 100 would be added tothe order book in step 322, with no further matches being found in step326. Thus, it will be appreciated that the embodiments hereincontemplate different possible matching techniques for the orders basedon, for example, the particular needs of an application, instrument, orsituation.

In certain example embodiments, the displayed price of a contra-side mayact as a limiter on how far a discretion order may “reach.” In otherwords, even if a possible discretion price is beyond the displayedprice, the system will still use the displayed price for a match ratherthan the full discretion price of an aggressing order.

In certain example embodiments, post-processing (e.g., as discussed inconnection with FIGS. 4A and 4B) occurs upon finding a valid match andmay thus occur subsequent to step 310/312 and/or step 326/328. Incertain examples, these processes occur subsequent to each match, thusif multiple matches are found for an order (e.g., order 220), theprocessing may occur each time a trade is identified.

FIG. 4A

FIG. 4A is a flow chart showing example post-processing for orders thatare matched and have the midpoint attribute.

In step 400, a valid match that involves a midpoint order is found. Whena midpoint order is matched against another midpoint order, a discretionorder, or a regular order, the details of that order are not madepublically available via a market-data feed or the like (e.g., all ofthe midpoint order is private). Accordingly, in step 402, the details ofthe trade that involves the midpoint order are only sent to thecounterparties for the trade.

In step 403, if there is no remainder for the midpoint order that wasmatched, then the process returns at step 410. If there is additionalquantity left over after execution of the trade, then the process movesto step 404 where it is determined if the remaining unmatched quantityof the order is greater than or equal to a size limit for midpointorders.

In step 406, if the remaining quantity is not greater than the sizelimit, the order is canceled. And the process returns at step 410. Incertain example embodiments, a customer associated with the midpointorder may be given the opportunity to increase the size of the order toat least meet the minimum size requirement.

In step 408, if the remaining quantity of the midpoint order is greaterthan or equal to the size limit, then the midpoint order remains in theorder book with its remaining quantity. The process proceeds to step 410and returns (e.g., to the processing in FIG. 3).

FIG. 4B

FIG. 4B is a flow chart showing example post-processing for orders thatare matched and have the discretion attribute. In step 450, a validmatch that involves a discretion order is found. If the match is withanother order at a price that is private, then the trade occurs in thedark and the details of the trade are only transmitted to thecounterparties in step 454. For example, if a resting discretion orderand an aggressive regular order match at a price between the bidoffer/spread (assuming the regular order satisfies the block sizerequirement to match against discretion orders), the details of thattrade will not be made publically available through a standard thirdpart market-data feed. If, however, the aggressive regular order matchesat the displayed price of the resting discretion order (e.g., it doesnot satisfy the discretion size requirements), then the trade details ofthat order will be transmitted via public market data feeds in step 452and the trade details of the executed trade will also be transmitted tothe counter-parties.

In step 455, the process adjusts the total quantity for the discretionorder based on the matched quantity in the executing trade. For example,when order 220 is matched with order 203, the total quantity of order220 is decreased from 1500 to 1100.

In step 456, the process determines if there is remaining quantity forthe discretion order, if there is no remaining quantity (e.g., the orderhas been fulfilled), the process returns at step 458.

If there is remaining quantity, the process moves to step 460 todetermine if the remaining quantity is greater than (or equal to) thesize requirement for discretion orders. Referring back to the example ofFIG. 2A, the size requirement for an order to use discretion would be100.

If the remaining quantity is less than the size requirement, then thediscretion attribute of the discretion order is removed in step 462 andthe order become a regular order with (potentially) a hidden size. Forexample, order 204 may have previously been a discretion order until thetotal size of the order dropped below 100. After adjusting thediscretion attribute, the process returns in step 472. Conversely, ifthe size limit is meet in step 460, then the process returns at step472.

In certain example embodiments, an order book may not have a two-sidedmarket (e.g., there are only bids or only offers in the order book). Forexample, the order book for an instrument may only include bid sideorders 200 as shown in FIG. 2A (without any offer side orders). In sucha situations, midpoint orders are marked as inactive. Further, restingdiscretion orders that are subsequently crossed by aggressingcounter-party order will only execute with 1 tick of discretion awayfrom the maximum discretion price of the aggressive order. Accordingly,if an order is displayed at price A and has 3 ticks of discretion and anaggressing (or newer) order, which meets the minimum discretion sizerequirement is placed at the price of A, then the match will occur at 1discretion tick from the price of A. As this trade occurs at a hiddenprice, the trade is executed in the dark.

This technical matching implementation may have the following benefits.First, it protects the passive trader that has multiple ticks ofdiscretion on the resting order. The trader is thus not giving upsignificantly more value than what the aggressing party was willing totrade at. Second, it rewards the aggressor with the one tick ofdiscretion (e.g., a better price than that at which they submitted theorder) and removes the need to search for discretion, prior tosubmitting an aggressive order. Third, while the aggressing order mayleave a little bit of price difference on the table, and the restingorder may pay up more than just the displayed price, on balance for bothsides have found liquidity at a fair price. The above one-sided marketexample may be an additional modification to the order matching processdiscussed in connection with FIG. 3 (e.g., elements 310 and 312).

In certain example embodiments, customers (e.g., based on the client IDin element 104) can only submit orders, per side of an order book, thatare orders with discretion or midpoint orders, but not both at the sametime. In certain example embodiments, clients may submit both ordertypes.

As described above, using midpoint or discretion orders restricts whichcontra-orders can be a valid match based on the size of thecontra-orders. Alternatively, or in addition to these restrictions,other restrictions may be placed on orders. For example, an order thatis executed with discretion may be restricted to certain types ofcustomers associated with a counter-party order. Such an implementationcould provide customized liquidity to certain customers (or types ofcustomers). Thus, a market maker could restrict discretion orders (or apart of a discretion order) to client of the market marker. A client canthus customize how its liquidity can be used. In another example,primary dealers could sponsor their own clients and offer them liquiditythat trades with discretion and/or at a midpoint. Other types oftargeting for orders may also be implemented based on the properties ofthe counterparty order (or client that is submitting the counterpartyorder).

In certain example embodiments, while real-time market data of tradesthat are executed in the dark are not made available to the public, suchinformation may be controllably released in the form of a total volumefor a particular instrument at a configurable time interval—e.g.,hourly, every 3 hours, end of day, etc.

In certain example embodiments, the inclusion of different order typesinto a single order book can create a more unified handling of orders(e.g., a better liquidity pool) for a given instrument identifier andmay make it easier for customers to act between the bid/offer spread(e.g., at wholesale prices). These techniques may be advantageous forinstrument identifiers that have low volatility and may not have thebid/offer spread for the instrument move during a trading day (e.g.,U.S. treasuries).

FIG. 5

FIG. 5 is a block diagram of an exemplary computing system 500 (whichmay also be referred to, for example, as a “computing device” or a“computer system”) according to certain example embodiments (e.g., anexchange computing system as described in FIG. 1, a user device as shownin FIG. 1, etc. . . . ). Computing system 500 includes a processingsystem 502 with CPU 1, CPU 2, CPU 3, CPU 4, a system bus 504 thatcommunicates with RAM 506, and storage 508. The storage 508 can bemagnetic, flash based (e.g., for a mobile client device), solid state,or other storage technology. A storage system may comprise cache memorythat are on the computer chip of CPU 1, RAM 506, storage 508, hardwareregisters, external systems 522, and the like.

The system bus 504 communicates with user input adapter 510 (e.g., PS/2,USB interface, or the like) that allows users in input commands tocomputing system 500 via a user input device 512 (e.g., a keyboard,mouse, touch panel, or the like). The results of the processing may bedisplayed to a user on a display 516 (e.g., an LCD) via displayinterface 514 (e.g., a video card or the like).

The computing system 500 may also include a network interface 518 (e.g.,a transceiver) to facilitate wired (e.g., Ethernet—802.3x) and/orwireless communication (WiFi/802.11x protocols, cellular technology, andthe like) with external systems 522, databases 520, and other systemsvia network 524. Transceivers may comprise circuitry for a transmitterand a receiver. The transmitter and receiver may share a common housingand may share some or all of the circuitry in the housing to performtransmission and reception. In some embodiments, the transmitter andreceiver of a transceiver may not share any common circuitry and/or maybe in the same or separate housings.

External systems 522 may include other processing systems, systems thatprovide third party services, computing nodes such as miners for theblockchain, etc. External systems 522 may be client devices or serversystems.

External systems 522 may also include network attached storage (NAS) tohold large amounts of data. External systems, along with the internalstorage and memory, may form a storage system for storing andmaintaining information (e.g., order book information, routingstrategies, etc. . . . ). Such a system may communicate with usersand/or other computing systems that process electronic order datamessages. The database 520 may include relational, object orientated, orother types of databases for storing information (e.g., order bookinformation for a financial instrument, trade information between twoparticipants, etc. . . . ).

In other words, the processes, techniques, and the like, describedherein (for client devices, server, exchange, and/or controller systems)may be implemented on a computing system. Such implementations may thenconfigure or program the processing system to carry out aspectsaccording to certain example embodiments. It will be appreciated thatother architecture types may be used. For example, a single CPU may beused instead of multiple CPUS. Alternatively, a processing system mayinclude multiple CPU “cores.” Further, the various elements shown inconnection with FIG. 5 may be included into one cohesive physicalstructure (e.g., such as a tablet device). The components andfunctionality shown in FIGS. 1-4B and 6-8B may be implemented on or inconjunction with the example computing system shown in FIG. 5 (e.g., tothereby create a specific purpose computing machine).

The computing system may be arranged, in various embodiments, in manydifferent ways. As just one example, the computing system may bearranged such that processors include: a multi (or single)-coreprocessor; a first network interface device (which implements, forexample, WiFi, Bluetooth, NFC, etc. . . . ); a second network interfacedevice that implements one or more cellular communication technologies(e.g., 3G, 4G LTE, CDMA, etc. . . . ); memory or storage devices (e.g.,RAM, flash memory, or a hard disk). The processor, the first networkinterface device, the second network interface device, and the memorydevices may be integrated as part of the same SOC (e.g., one integratedcircuit chip or a “system-on-chip”). As another example, the computingsystem may be arranged such that: the processors include two, three,four, five, or more multi-core processors; the network interface devicesinclude a first network interface device that implements Ethernet and asecond network interface device that implements WiFi and/or Bluetooth;and the memory devices include a RAM and a flash memory or hard disk.

As described herein when a software module or software process performsany action, the action is in actuality performed by underlying hardwareelements according to the instructions that comprise the softwaremodule. In various embodiments, each or any combination of the matchingengine processor 108, order book 110, client system(s) 102, exchange100, external electronic exchange systems 114, exchange 600, clientsystem(s) 602, etc. . . . , each of which will be referred toindividually for clarity as a “component” for the remainder of thisparagraph, are implemented using an example of the computing system 500of FIG. 5. In such embodiments, the following applies for eachcomponent: (a) the elements of the 500 computing system 500 shown inFIG. 5 (i.e., the one or more processors 502, one or more memory devices506 or 508, one or more network interface devices 518, one or moredisplay interfaces 514, and one or more user input adapters 510), orappropriate combinations or subsets of the foregoing) are configured to,adapted to, and/or programmed to implement each or any combination ofthe actions, activities, or features described herein as performed bythe component and/or by any software modules described herein asincluded within the component; (b) alternatively or additionally, to theextent it is described herein that one or more software modules existwithin the component, in some embodiments, such software modules (aswell as any data described herein as handled and/or used by the softwaremodules) are stored in the memory devices (RAM) 506 and/or (Storage) 508(e.g., in various embodiments, in a volatile memory device such as aRAM, in an instruction register, and/or in a non-volatile memory devicesuch as a flash memory or hard disk) and all actions described herein asperformed by the software modules are performed by the processors 502 inconjunction with, as appropriate, the other elements in and/or connectedto the computing system 500 (i.e., the network interface devices 518,display interfaces 514, user input adapters 510, and/or display device516); (c) alternatively or additionally, to the extent it is describedherein that the component processes and/or otherwise handles data, insome embodiments, such data is stored in the memory devices (e.g., insome embodiments, in a volatile memory device such as a RAM and/or in anon-volatile memory device such as a flash memory or hard disk) and/oris processed/handled by the processors 502 in conjunction, asappropriate, the other elements in and/or connected to the computingsystem 500 (e.g., the network interface devices 518, display interfaces508, user input adapters 510, and/or display device 516); (d)alternatively or additionally, in some embodiments, memory devices storeinstructions that, when executed by the processors 502, cause theprocessors 502 to perform, in conjunction with, as appropriate, theother elements in and/or connected to the computing system 500, each orany combination of actions described herein as performed by thecomponent and/or by any software modules described herein as includedwithin the component.

Elected Discretion

In certain examples embodiments, a central limit order book (CLOB)electronically (e.g., electronic order book 110) maintained (e.g., on aprice/time basis or other sorting basis) by an exchange (by exchange 100or 600) includes a “dark pool” or hidden orders (e.g., orders that areentirely private or have private attributes). The exchange streamsmarket (e.g., order) information (e.g., 500 shares of X is offered at100) to market participants who can then act on the displayedinformation. The stream information is valid until it is fulfilled(e.g., a trade is executed) or the order is canceled. In certainexamples, the streamed information is anonymous so that the parties toan executed trade will not expressly know the identity of theircounter-party. The streaming techniques of a CLOB are in contrast toso-called quote-based order techniques where market participants ask fora quote for a given instrument (e.g., I would like a quote for 500shares of X).

In certain instances, market participants (sometimes referred to asclients) can “elect” who (e.g., a category or group of other marketparticipant or client types) can execute against the private attributesof their orders. Private attributes include orders that are traded at amidpoint price (a private attribute) and/or orders that can execute at adiscretion price (another type of private attribute). Private attributesmay also include orders that have a private “reserve” size associatedwith the order (e.g., “elect reserve” as discussed below). By using theelect attribute for an order, a market participant can know whichparticipant type their private order (or private attribute of a regularorder) has executed against, while not knowing the exact identity of thecounter party (and vice versa). In a CLOB implementation, private orders(e.g., a midpoint order) or the private attributes of regular orders(e.g., an order that can execute with discretion at another price level)are not included in any public market data feed that is streamed to thepublic. Instead, this information is kept by the exchange and his“hidden” or kept private from the general public (e.g., marketparticipants). As explained herein, there may be different factors orrules that determine when a hidden order can execute against anotherorder.

In certain example embodiments, the ability for order submitting clientsto use the elect functionality is controlled on an instrument byinstrument basis. For example, an electronic exchange computing systemthat trades various types of bonds may only offer this functionality forcertain U.S. treasury benchmark bonds.

FIG. 6

FIG. 6 illustrates a non-limiting example function block diagram of acomputer-implemented exchange system 600 configured to receive orderswith private order properties that have an elect attribute according tocertain example embodiments. Client system 602 is configured tocommunicate with exchange 600 (e.g., which may be exchange 100 as shownand described herein) over electronic communication links to submitelectronic messages that include electronic data requests. An exampleelectronic data request is the submission of a new order as indicated inFIG. 6. It should be noted that exchange 600 may be a modified versionof exchange 100 (e.g., programmed process the functionality described inFIGS. 6-8B).

Order 604 is an example of an order that can execute with discretion(e.g., as described above) and includes data values that indicatevarious properties of the order including the price, the discretionprice (or number of discretion ticks), size, instrument identifier(e.g., a ticker), and the like. Order 604 also includes an electattribute data field indicates which type of market participant order604 can be matched against (for the private part of the order).

The data field for the elect attribute 606 can be a bit mask (e.g., of16 bits, 32 bits, or other size) where each bit that is turned “on”indicates a different eligible client group. As shown in FIG. 6, bit 1606 a is for “primary dealers,” bit 2 606 b is for “broker dealers,” bit3 606 c is for “banks,” bit 4 606 f is for standard orders only (whichis applied to legal entities that are not eligible for matching based onthe hidden attributes of a contra-side order), bit 15 606 d is for“internal use,” and bit 16 606 e is for “GUI user.”

For order 604, the second bit for broker dealer 606 b is specifiedindicating that order 604 will allow the hidden attributes of its orderto trade against other orders that are from market participants includedin the “broker dealer” group. However, if a new order does not specifyanything for the elect attribute data field 606 (or indicates that nogroups are eligible), then the exchange may attempt to match the neworder using its hidden attributes against any contra size order (e.g.,as long as other requirements are satisfied, such as price and sizerequirements).

In certain example embodiments, market participant groups are createdand managed by the operator of the exchange. A market participant thatinteracts with the exchange may be placed into one or more of the groupsthat have been defined by the exchange. For example, a client may beboth a bank and a primary dealer.

In certain example embodiments, there are two different types of marketparticipant groups. The first type classifies market participantsaccording to their legal entity status (e.g., as understood by theexchange, the market participant themselves, or certain regulatoryauthorities). This includes primary dealers, broker dealers, banks, andthe like. Legal entities can belong to multiple groups and entities thatare not placed into at least one group may not be eligible for tradingusing the elect attribute.

Another type of market participant group works outside of the abovelegal entity types. These include “internal” and “GUI user” types. Theinternal type provides eligibility to users that belong to the samelegal entity. In other words, if a market participant specifies itsorder is “internal” then it would only be authorized to trade againstother orders that are submitted from that same market participant.

The GUI user type indicates the order is eligible to trade againstorders that have been submitted using a customer client side applicationthat interfaces with the exchange computer system. An exampleapplication may be the eSpeed Trading Application available from Nasdaqthat provides users with a graphical user interface for submitting andreviewing trades to an exchange. In certain example embodiments, orderssubmitted through such an application are automatically identified assuch in addition to identification of the client group the userlDassociated with the order belongs to. In certain example embodiments,orders submitted from such an application may be recognized and eligibleto trade against other orders submitted form the application. It will beappreciated that other application types or applications may be added tothe bit mask. It will also be appreciated that other techniques forindicating eligible group IDs may be implemented according to certainexample embodiments. For example, a delimited list of identifiers may besubmitted as part of the order ID to indicate which group IDs areeligible.

In certain example embodiments, both the first “type” and the second“type” of elect preference may be indicated in the same order. Forexample, a new order may indicate both 606 d and 606 b. In such anexample, the order would be eligible to execute against any ordersubmitted by that market participant or any other market participantthat was classified as a broker dealer.

In certain example embodiments, additional market participant groups maybe defined and/or created by the operator of the exchange. In certainexample embodiments, the user IDs (e.g., individual logins) associatedwith a market participant are assigned to the market participant groupassociated with that specific market participant. In certain exampleembodiments, individual user ids may be associated with other specificmarket participant groups (e.g., thus overriding or supplementing thedefault association).

In certain example embodiments, the elect attribute is only applied toresting orders. As described herein, when a new order with discretion isreceived, a matching process (e.g., steps 310 and 312 in FIG. 3) isexecuted to find a match without using the discretion property of thenew order (although the discretion attribute of the orders that areresting in the CLOB may be used). If no match is found during this firstmatching process, the order is added to the CLOB, and the matchingengine processor may run a second matching process for the restingorders (that now includes the newly added order).

FIGS. 7-8B

FIG. 7 is a flow chart that shares elements with FIG. 3 and showsanother example matching process implemented for orders include theelect attribute according to certain example embodiments. Most elementsin FIG. 7 work as described above with respect to FIG. 3. The elementsthat may operate differently for orders that include an elect attributeare in steps 699, 700, and 702. FIG. 8A shows an example order book foran instrument that includes some orders with the elect attribute. FIG.8B show example incoming orders that may be executed against the orderbook shown in FIG. 8A.

In step 699, when a new order is received, the client that submitted theorder is known to the exchange (e.g., based on an association betweenthe user ID that submitted the order and a client ID). As discussedabove, clients (either on a user level or a legal entity or clientlevel) may be associated with different market participant groups.Accordingly, in step 699, the market participant group or groupsassociated with the new order may be determined and added to theattributes of the new order (e.g., the client “type” of the order may bedefined). In certain examples, this information may already be presentin the data fields included in the newly submitted order.

In certain example embodiments, the exchange may validate the electattributes for an order. If an order has improper elect attributes, theexchange may generate an error message and sent a responsive datamessage indicating the order (e.g., the limit portion of the order) willnot be maintained.

In step 700, when a new order is received the matching engine processorattempts to match the new order with contra-side resting orders in theCLOB considering the elect preferences of the orders. During thismatching process, the matching engine processor may use hiddenattributes (e.g., hidden size and/or price) of the resting orders forfulfilling the new order. However, if a resting order (e.g., midpointorder or an order that can execute with discretion) indicates its hiddenattributes are only eligible for certain market participant groups(e.g., by referencing the relevant group participant identifiers) ofwhich the client that submitted the new order is not a member of, thenthe matching engine processor will not use the hidden attributes of thatorder for this matching process.

If no match is found, then, in step 702, the matching engine processormay select one order as an “aggressive” order and filter the contra-sideof the electronic order book based on the elect attribute for thatorder. The matching engine processor may then attempt to match thefiltered order book using the discretion price of the resting orders. Incertain example embodiments, orders included after the filtering mayhave their elect attributes processed as well. In other words, whileorder “A,” from a client in group “X” may indicate orders in group “Y”are valid through the elect attribute, a contra-side order “B” of group“Y” may indicate that orders in group “X” are not eligible. Thus, evenif order B is included in a filtered version of the order book for orderA, no match will be found between these two orders at a hidden price orsize.

In certain example embodiments, a matching engine processor may have adiscretion market zone attribute that controls the maximum depth anorder with discretion will be considered by the matching engineprocessor. This attribute may be from 0 to another number. A value of 0may indicate that the discretion price will only be considered for thoseorders that are displaying the best price (e.g., at the top level of theorder book). A value of 1 may indicate that orders with displayed prices1 tick below the current top level may have their discretion pricesconsidered during the matching process. This attribute may beconfigurable on an instrument-by-instrument basis and/or on aclient-by-client basis (e.g., certain client groups may have a value of0 applied to their orders, while orders from another client group mayuse a value of 2).

Consider the following examples by referring to FIGS. 8A and 8B, neworder 820 in FIG. 8B is submitted by a client of market participantgroup 2 (indicated by the “client type” data field). This order will beprocessed against the CLOB of the exchange shown in FIG. 8A, withpending bid orders 800 and pending offer orders 810. New order 820 is anorder that can execute with discretion against orders from marketparticipants of group 1 (as indicated by the “elect” data field). Inapplying this new order to the order book shown in FIG. 8A, the matchingengine processor will first (e.g., in step 700 of FIG. 7) attempt tofind a match at the displayed price (101) for this new order. In certainexample embodiments, as the price of the new order is at the “displayed”price, the elect preferences for the new order are ignored. In otherwords, the elect attribute is only used to filter when matching based onthe discretion or other hidden attributes of the order.

As shown in FIG. 8A, both order 803 (a midpoint order with the midpointcurrently at 101) and order 801 (an order that can execute withdiscretion up to 101) can satisfy the “displayed” asking price of 101 oforder 820. However, the matching engine process will skip over (e.g.,based on the CLOB being ordered in price/time priority) order 803because it has an elect attribute of “3” indicating that it will onlymatch against contra-side orders submitted by clients that are in group3. As order 803 is a midpoint order, it is completely hidden and theelect attribute for that order applies to any execution of that order.Order 820 was submitted by a client from group 2, and therefore failsthe group “3” requirement of order 803, and no trade occurs.

In contrast, order 801 indicates that clients from groups 1 or 2 areeligible for its “hidden” attribute. The hidden attribute of order 801is the discretion price (101) that it may execute at. Accordingly, amatch is identified between order 801 and order 820 at a price of 101for 500. This order executes in the “dark” as the matching engineprocess uses the discretion attribute of order 801 to complete theorder. After executing this trade, the remainder (displayed size of 75and total size of 1000) of order 820 is placed into the central limitorder book on the offer side.

After placing the remainder of order 820 into the CLOB (e.g., in step322 of FIG. 7), another matching process in step 702 is performed by thematching engine processor (or another matching engine processor) on theresting orders of the CLOB. The matching process here is similar to thatin step 326 of FIG. 3, but here the elect attributes of both sides ofthe order book are used for matches that make use of the hiddenattributes of orders. Thus, with order 801 fulfilled, order 820 isresting in the order book at a price of 101 and can optionally executeat 100.5—one discretion tick away from its displayed price. In addition,as a result of having the spread shrink from 100-102 to 100-101, theeffective price of midpoint order 803 is recalculated to 100.5. But, asdiscussed above, midpoint order 803 will not trade with orders fromclients outside of group 3. In contrast, order 802 is another discretionorder that, while displaying a price of 100, can execute at 100.5—onetick away from its displayed price. Unlike order 803 and order 801,order 802 (also an order from a client of market participant group 1)does not specify elect preferences and accordingly any contra-side orderthat satisfies the size, price, and/or other “hidden” attributerequirements will fulfill order 802. Here, order 820 satisfies theminimum size requirement and a match is identified between order 802 andorder 820 at 100.5 for 500. This trade is executed using discretion andaccordingly the result of the trade is not included in a public marketdata feed. There are no other orders that order 820 can match againstand accordingly order 820 will remain in the CLOB with a displayed sizeof 75 at a displayed price of 101 with a total size of 500 and one tickof discretion execution.

In certain example embodiments (e.g., as discussed below), an order thathas its total size completely (or partly) consumed at a discretion pricemay remain in the order book at the displayed price and size. Forexample, upon fulfilling 500 of order 801, order 801 may remain in theorder book with a display size of 25 and a displayed price of 100. Incertain example embodiments, a client can then modify this order tobring the “total” or reserve size of the order back up to 500 (or someother size that satisfies the minimum discretion size requirement.

Returning to FIG. 8B, order 830 shows another example of how the electattribute can be used against the example order book shown in FIG. 8A.Order 830 does not have a specified elect attribute and was submitted bythe same legal entity that submitted order 803 (e.g., in client group1). Accordingly, in step 700 the matching engine will try to find amatch at a price of 101. While order 803 indicates that 3 is one of itselect attributes (which is not the client type of the client thatsubmitted order 830), it also has bit 15 as an elect attribute.Accordingly, order 803 can trade against orders from client group 3(banks) and also other orders that have been submitted by that sameclient. Here, order 830 and 803 have been submitted by the same clientand accordingly a match is identified between 803 and 830. This matchwill trade in the “dark” (nothing regarding this particular trade isgenerated on standard real-time market data feeds) as it is at themidpoint price.

After identifying this match, no further matches are found because order801 will only trade with clients in group 2—which does not include theclient that submitted order 830. Accordingly, order 830 will be added tothe CLOB with a displayed price of 101, a displayed size of 100, and atotal size of 100 (same as the displayed size).

In certain example embodiments, a client can modify attributes of aresting order. For example, after execution of order 830, a client maymodify the total size of the order back up to 500 (while keeping thedisplayed size of 100). In certain example embodiments, suchmodifications will not affect the stack position of the order. In otherwords, even if the modification comes after other orders have beenaccepted and added to the order book at a price of 101, the timestamp ofthe modified order will remain unchanged (e.g., remain at 9). Thus, thediscretion parts of an order (e.g., the hidden size) may be associatedwith the top or first stack position of the corresponding displayed partof the order that is already resting in the CLOB.

In other implementations, when an order is modified (e.g., to increaseits size), the additional quantity is placed at the bottom of the orderbook. In other words, if client A submits a bid at 100 for 5 and clientB then submits a bid at 100 for 10, and then client A modifies theoriginal order with an additional 5, the “stack” of the order book maybe 5, 10, and 5. Thus the second 5 that was input to “modify” the firstorder will be executed after the 10 from client B. However, as describedherein, when hidden attributes of an order are modified themodifications as associated with the top position in the order book.Thus, in the above example, if the second 5 was a modification to thereserve or hidden portion of the first order it will execute before the10 from client B.

In another example, and after the execution of order 830, the client oforder 801 may cancel (or modify its elect attribute) so that a match maybe identified between resting order 830 and resting order 801. Inparticular, in response to modifying (or canceling) the elect attributeof order 801, the exchange may run a matching process on the restingorder book (e.g., the matching process described in step 702). Incertain example embodiments, any action that touches or affects thestate of the CLOB, may trigger execution of a matching process todetermine if a match can be identified (e.g., as the state of the CLOBhas changed).

In certain example embodiments, an order executed with discretion can beimplemented as two or more separate orders that are linked. A firstorder will be an order with a displayed price and a displayed quantity.A second order may be an order that includes a hidden price and a hiddenquantity. These two orders will be linked by the exchange 600. Forexample, the second order may include a parent order field thatindicates the first order is its parent order. Accordingly, when a matchis found with the second order it may correspond to the discussionherein of being at the discretion price of the first order. In certainexample embodiments, when the displayed order (the first order) isfulfilled, then any child orders (e.g., the second order) are canceled.

In certain example embodiments, the exchange may track which orders areexecuted with discretion and apply and/or calculate a fee for the ordersthat received the benefit of the discretion. For example, a standardorder (e.g., order 240) executed with discretion (e.g., against acontra-side order with discretion or a midpoint order) may have adiscretion fee calculated and applied to it. In certain exampleembodiments, opposing discretionary orders that match/cross will eachhave a fee or surcharge calculated and applied. In certain exampleembodiments, opposing midpoint orders which match each other may eachhave a block surcharge calculated and applied. In certain exampleembodiments, different surcharges for using discretion and/or discretionthat includes the elect attribute may be applied to both passive andtaker orders for instruments offered by the exchange

As explained above, the exchange may operate on a price/time basis. Incertain example embodiments, the priority of how orders are matched mayalso be based on certain elect attributes. For example, an order withelect bit 15 (internal) that can execute against an order from the sameclient may be prioritize over an earlier submitted order from adifferent client that is at the same price.

In certain example embodiments, electronic data messages sent to thecounter-parties may include a trade property attribute that identifieswhich group the counter-party for the executed trade belonged to. Theelectronic data message may include a flag that identifies which portionof the matched order was executed using elect and/or discretionproperties.

Elect Reserve

In certain instances, order submitting clients may be concerned howtheir quotes impact the market. This may have an adverse side effect ofclients reducing the size of orders posted to the CLOB to avoidattracting predatory activities. In certain example embodiments, clientscan direct and/or limit a portion of their order to groups/categories ofusers (or legal entities) that they are more willing to trade with(e.g., such counter-parties may be understood to be less aggressive innature).

In certain example embodiments, clients can indicate a reserve size(e.g., hidden size) for this order that is accessible only to qualifiedusers (or legal entities) with an associated eligibility list (e.g., asdescribed above and in FIG. 6). Elect reserve allows clients (e.g.,liquidity providers) to “elect” eligible recipient client group(s) theywish to offer additional size. As with the above described electdiscretion, these features may be applied on an instrument-by-instrumentbasis (e.g., not available on all instruments) that are traded on agiven exchange (e.g., exchange 100 or exchange 600).

In certain example embodiments, the exchange can require a minimum showsize for a newly submitted order with a hidden reserve size. Similarly,the exchange may require the reserve size to meet a minimum reserve sizerequirement. These two variables may be indicated byElectMinimumShownSize and ElectMinimumReserveSize values and may vary onan instrument-by-instrument basis. If a client attempts to reduce apreviously submitted valid order below either of these thresholds, theexchange may reject such modifications (or cancel the order).

Turning back to FIGS. 8A and 8B, consider the execution of order 840against the CLOB shown in FIG. 8A (e.g., without modification based onthe other examples discussed above). In this example, order 102 willmatch against order 812. Order 812 has a displayed size of 100, areserve or hidden size of 1000 and indicates that contra-side ordersfrom clients of type 1 (primary dealers) or 16 (GUI user) may access andtrade with its hidden size. Order 840 has been submitted by client type1 and accordingly the full reserve size of order 812 is eligible fortrading. The result of this trade will be a trade for 500 at 102 and thereserve size of order 812 will be reduced to 500, while the displayedsize remains at 100. As this trade used the elect attribute and was theresult of accessing the reserve or hidden size of order 812, no publicindication of the details of this trade will be sent out through apublic real-time market data feed. Instead, details of the trade will bedirectly reported to the counter-parties for the trade. As explainedbelow, aspects of this executed trade (e.g., the volume) may be includedin a time-delayed report that is sent out on a rolling basis by theexchange.

Another example is shown in FIG. 8B if order 850 is executed against theCLOB shown in FIG. 8A. Order 850 is for the same amount as order 840.However, order 850 has been submitted by a client in group 2—a groupthat is not included in the elect attribute for order 812. Accordingly,the reserve size of order 812 is not available to order 850. As aresult, only the displayed size of order 812 is available for tradingand there will be a resulting match for 100 at 102 between order 850 andorder 812 and then for 50 between order 850 and order 811. The remaining350 of order 850 will be added to the bid side of the CLOB at 102 (notethat this will result in order 803 becoming invalid as there is no validbid/offer spread to base the midpoint on).

Another example of an example matching process is described inconnection with order 860 in FIG. 8B. Here, order 860 has a displayedsize of 100 and a total size of 500 (e.g., a reserve size of 400). Whenorder 860 is received a matching process is performed that uses theelect attribute of order 860 (“1”). In this example, order 860 willexecute against order 812 for its displayed size of 100 because order812 is from client type 2, which is not the client group indicated byorder 860's elect attribute. As a result of the executed trade between812 and 860, the displayed size (100) of both orders has been fulfilled.In certain example embodiments, when the displayed size of an order isfulfilled, the remaining reserve size (if any) of the order is canceled.In certain instances, canceling the order may make it more difficult forcounter-parties to infer the hidden size offered by order 812. In otherwords, the elected reserve portion of order 812 may not be re-clippedand posted to the CLOB.

The displayed size of order 860 is also 0 and thus this new order mayalso be canceled. In certain example embodiments, a new order that hasits displayed size fulfilled may attempt to continue matching based onlyon the reserve size (and elect preferences). In other words, thematching engine processor, after matching 860 and 812, may determinethat a match can also be executed between 811 and 860 because order 811is of client type 1. In certain example embodiments, this match may beperformed in the dark (e.g., because the reserve size of order 860 isbeing used). Alternatively, in certain example embodiments, the trademay be publically reported via real-time market data feeds because order811 had a displayed size of 50. In certain example embodiments, publictrade execution messages may be sent for the displayed size and not forthe reserve size that has been executed (e.g., if order 811 had 100total size, 50 would be publically reported and the other 50 would be inthe dark).

In certain example embodiments, newly submitted orders that have areserve size, but do not specify any elect preferences may be re-clipped(e.g., matched orders will “take” from the reserve portion and theremainder of the order will be displayed in the CLOB).

In certain example embodiments, an order that was submitted with electreserve attributes will remain in the CLOB until the displayed size isexhausted or the order is canceled by the client. In certain exampleembodiments, even if the reserve size falls below theElectMinimumReserveSize as a result of executed trades, the order willremain in the CLOB.

In certain example embodiments, if the reserve size (or other “private”property) of an order is modified by a client, the resting position ofthe order in the order book will not be affected. In certain exampleembodiments, if a reserve size (or other hidden property like adiscretion price) is added to an existing order, the resting position ofthe modification will be associated with the displayed portion of theorder. On the order hand, if the displayed size is changed, then theresting position of the order may be affected. In certain examples, thereserve portion of an order will maintain the position of the shownportion of the order.

In certain example embodiments, new orders that are from eligible groups(e.g., order 840 in FIG. 8B) for contra-side orders will matchdiscretely against the reserve size of the contra-side order prior tomatching against the displayed size. In certain example embodiments, thedisplayed size and the reserve size are independent sizes for an order.For example, order 812 may have a displayed size of 100 with a reservesize of 1000. Effectively, order 812 is offering 1100 at 102, but withonly 100 being offered to any counter party.

In certain example embodiments, matches and the subsequent tradesexecuted using discretion properties may be confirmed independently oftrades executed in the standard or visible CLOB. For example, if anorder is partly matched against some reserve size and a remainder of thedisplayed orders in the CLOB, the order submitting client may receivetwo confirmation messages for the execution of their single order. Thefirst message may indicate what portion of the submitted order wasexecuted using the reserve elements (or other hidden attributes) of theorders in the order book. The second may indicate that the remainingbalance was executed against the displayed portion of the order book(e.g., if the new order matched against two different orders for adisplayed price, those two matches may be reported as one trade.

In certain example embodiments, an order may satisfy and use electreserve functionality and elect discretion functionality. In certainexample embodiments, a trade executed using a discretion price will usethe reserve size of a contra-side order before hitting the displayedsize. In certain example embodiments, a trade executed at a lit pricewhen a counter party satisfies the elect attribute requirement of theother order will use the reserve portion of the order before hitting thedisplayed size. In certain example embodiments, a trade executed at alit price where one order is not eligible according to the electattribute of the contra-order uses the lit or displayed size of theorder and will not re-clip from the reserve size of the order.

Volume Reporting

As discussed herein, when an order is executed using a hidden or darkproperty (e.g., with discretion, midpoint orders, elect reserve, electdiscretion, and/or elect midpoint orders) the results of the executedtrades will not be made publically available through standard electronicmarket data feeds. In certain example embodiments, an exchange maypublish the volume associated with these “dark” transactions on adelayed and/or configurable basis. In certain example embodiments, anexchange may define a configurable option on an exchange, instrument, orinstrument group basis.

In certain example embodiments, an exchange may define a value (e.g., a“dark volume delay” property) that indicates the amount of time betweenwhen a dark trade has occurred and when the volume of that trade isincluded in a volume report. For example, if the dark volume delay isset to 5, then the every 5 minutes the computer system will update the“real-time” total “lit” volume with the volume that occurred in the“dark” minus 5 minutes. The volume that is reported in this manner isreported without any indication of price.

For example, an exchange may offer an instrument (e.g., 2 year U.S.treasury) and the exchange may provide real-time updates of the volumefor that instrument throughout the day. Accordingly, if the real-timevolume for an instrument is 300, and the reporting period for “dark”trades from 5 to 10 minutes ago indicates that 50 was traded in thedark. The exchange may provide an indication that the “real-time” volumeis 300+50 volume (as of the current time minus 5 minutes). The delayedvolume number may be updated as the “real-time” number is updated. Inother words, the exchange may continually provide a report of how muchhidden volume was transacted between 5 and 10 minutes from the currenttime period.

In certain example embodiments, the volume reported is a delayed totaldark volume. Thus, the “real-time” lit total (e.g., for that tradingday) volume may be reported with the total “dark” volume minus 5 minutesago for that trading day. Naturally, the time period is configurable andmay be, for example, any value between 1 minute and 1 hour or even 1second and 1 day (or greater).

In certain example embodiments, these two volume numbers are providedseparately. In certain example embodiments, the exchange will simply addone number to the other and report the result with no indication as tohow much of the volume is due to “dark” transactions and “lit”transactions.

In certain example embodiments, the operator of the exchange may have aconfigurable property to enable and disable such volume reporting on atleast an instrument-by-instrument basis.

In certain example embodiments, a computer system may not maintain darkvolume separately for failover purposes. In certain example embodiments,a trading system will continue to maintain total volume traded that willbe total lit volume plus total dark volume (as of a delayed timeperiod). In other words, volume traded in the “dark” may only stay“dark” for continuation of the current session. With the start of thenew trading session, the total volume is combined and the dark volume isreset.

Thus, during a failover event (e.g., soft, hard, or disaster recoveryevent) the system will report, for conflated and real time market data,the volume reported will be the total traded volume up to the event thatincludes lit and dark just prior to failover. In certain instances, amarket data feed that provides volume information (e.g., such as theITCH protocol), may restart from zero.

Technical Advantages of Described Subject Matter

In certain example embodiments, the subject matter described hereinprovides for a more unified handling of pending and received datatransaction requests by utilizing a single (per identifier) dual-sidedordered list (an order book) for match processing of the datatransaction requests. The techniques described herein may thus allow formore efficient processing and allowing an exchange to identify morematches between data transaction requests. In certain exampleembodiments, an exchange computing system may find potential matchesbetween different types of data transaction requests.

As noted above, the technical matching implementation may have thefollowing benefits. First, the search space for finding a match isinitially reduced as the aggressing order is processed using its publicprice. Second, the techniques also protect passive orders that havemultiple ticks of discretion. Accordingly, an order will not give upsignificantly more value than what the aggressing party was willing totrade at. Third, in certain examples, the aggressing order may beawarded with one tick of discretion (e.g., a better price than that atwhich the order would have been matched at). Fourth, while theaggressing order may leave a little bit of price difference (e.g., itmay have gotten “more” in another scenario) and the resting order maypay up (or down) more than just the displayed price—on balance for bothorders will have improvements over what they otherwise would have beenmatched at.

The techniques herein may facilitate the identification of more matchesthan would otherwise be identified. These techniques may be useful wherethe public values of data transaction requests in the ordered lists donot fluctuate very much as the private values may be used to foridentifying matches.

Selected Terminology

Whenever it is described in this document that a given item is presentin “some embodiments,” “various embodiments,” “certain embodiments,”“certain example embodiments,” “some example embodiments,” “an exemplaryembodiment,” or whenever any other similar language is used, it shouldbe understood that the given item is present in at least one embodiment,though is not necessarily present in all embodiments. Consistent withthe foregoing, whenever it is described in this document that an action“may,” “can,” or “could” be performed, that a feature, element, orcomponent “may,” “can,” or “could” be included in or is applicable to agiven context, that a given item “may,” “can,” or “could” possess agiven attribute, or whenever any similar phrase involving the term“may,” “can,” or “could” is used, it should be understood that the givenaction, feature, element, component, attribute, etc. is present in atleast one embodiment, though is not necessarily present in allembodiments. Terms and phrases used in this document, and variationsthereof, unless otherwise expressly stated, should be construed asopen-ended rather than limiting. As examples of the foregoing: “and/or”includes any and all combinations of one or more of the associatedlisted items (e.g., a and/or b means a, b, or a and b); the singularforms “a”, “an” and “the” should be read as meaning “at least one,” “oneor more,” or the like; the term “example” is used provide examples ofthe subject under discussion, not an exhaustive or limiting listthereof; the terms “comprise” and “include” (and other conjugations andother variations thereof) specify the presence of the associated listeditems but do not preclude the presence or addition of one or more otheritems; and if an item is described as “optional,” such descriptionshould not be understood to indicate that other items are also notoptional.

As used herein, the term “non-transitory computer-readable storagemedium” includes a register, a cache memory, a ROM, a semiconductormemory device (such as a D-RAM, S-RAM, or other RAM), a magnetic mediumsuch as a flash memory, a hard disk, a magneto-optical medium, anoptical medium such as a CD-ROM, a DVD, or Blu-Ray Disc, or other typeof device for non-transitory electronic data storage. The term“non-transitory computer-readable storage medium” does not include atransitory, propagating electromagnetic signal.

Individual function or process blocks are shown in the figures. Thoseskilled in the art will appreciate that the functions of those blocksmay be implemented using individual hardware circuits, using softwareprograms and data in conjunction with a suitably programmed hardware,using applications specific integrated circuitry (ASIC), and/or usingone or more digital signal processors (DSPs). The software programinstructions and data may be stored on non-transitory computer-readablestorage medium and when the instructions are executed by a computer, orother suitable hardware processor, control the computer or hardwareprocessor to perform the functionality defined in the programinstructions.

Although process steps, algorithms or the like may be described orclaimed in a particular sequential order, such processes may beconfigured to work in different orders. In other words, any sequence ororder of steps that may be explicitly described or claimed does notnecessarily indicate a requirement that the steps be performed in thatorder. The steps of processes described herein may be performed in anyorder possible. Further, some steps may be performed simultaneously (orin parallel) despite being described or implied as occurringnon-simultaneously (e.g., because one step is described after the otherstep). Moreover, the illustration of a process by its depiction in adrawing does not imply that the illustrated process is exclusive ofother variations and modifications thereto, does not imply that theillustrated process or any of its steps are necessary to theinvention(s), and does not imply that the illustrated process ispreferred. A description of a process is a description of an apparatusfor performing the process. The apparatus that performs the process mayinclude, e.g., a processor and those input devices and output devicesthat are appropriate to perform the process.

Although various embodiments have been shown and described in detail,the claims are not limited to any particular embodiment or example. Noneof the above description should be read as implying that any particularelement, step, range, or function is essential. All structural andfunctional equivalents to the elements of the above-described preferredembodiment that are known to those of ordinary skill in the art areexpressly incorporated herein by reference and are intended to beencompassed. Moreover, it is not necessary for a device or method toaddress each and every problem sought to be solved by the presentinvention, for it to be encompassed by the invention. No embodiment,feature, component, or step in this specification is intended to bededicated to the public.

1. A computing system for processing different types of data transactionrequests, the computing system comprising: a computer storage systemconfigured to store: at least a first list pair that is composed of afirst list and a second list, where a plurality of pending datatransaction requests is included in the first and/or second list, wherelist matches are determined between data transaction requests associatedwith the first list to data transaction requests associated with thesecond list, the plurality of pending data transaction requestsincluding a first data transaction request in the first list, whereinthe first data transaction request includes a public value, a privatediscretion attribute, and an elect attribute that indicates a firstparticipant group identifier out of a plurality of possible participantgroup identifiers; a transceiver configured to receive, from remotecomputing devices, electronic data messages that each include arespective data transaction requests, where a new electronic datamessage of the electronic data messages includes a new data transactionrequest; a processing system that includes at least one hardwareprocessor coupled to the computer storage system and the transceiver,the processing system configured to: perform, against the first list ofthe first list pair, a matching process for the new data transactionrequest, wherein the matching process includes: determining if the electattribute of the first data transaction request corresponds to a secondparticipant group identifier that is associated with the new datatransaction request, and matching the first data transaction request tothe new data transaction request by using the private discretionattribute of the first data transaction request; cause the transceiverto, as a result of the matching of the first data transaction request tothe new data transaction request by using the private discretionattribute of the first data transaction request, transmit executiondetails of the match to the respective participants of the match.